CodeLove 論壇 - 免費自學作業包＆新手友善討論區，幫你轉職工程師！

👉 讀技術文章 👉 上自學課程 👉 討論區交流

🔍 搜尋結果：`'

關於 Deno 和 Node 的未來

如果 Node 是今天寫的，它會是什麼樣子？一言以蔽之： [**Deno**](https://deno.land/) 。 JS 執行時內建了 Typescript 並簡化了模組解析。最重要的是，它將安全性提升到了一個新的水平，並縮小了我們在後端編寫 javascript 的方式與瀏覽器之間的差距。不久前 ... ------- 2009 年發布的 node 以令人難以置信的速度席捲了世界。儘管最初對在後端執行 javascript 持懷疑態度，但社區的支持是無與倫比的。很快，複雜的工具出現了，幾年後（2014 年），微軟發布了 Typescript，對 Javascript 進行了雙重押注。如今，Node 是後端開發最受歡迎的選擇之一。基於事件的伺服器理念確保了高效能/吞吐量比。執行 Javascript 對許多開發人員來說是一種易於使用的工具。在某種程度上，可以說，Node 透過降低進入門檻實現了後端開發的民主化。在過去的五年裡，我一直很高興地使用 Node，但同時，我想知道未來在等待著什麼？街區的新來者：Deno ----------- 如網站所述，Deno 專案於 2018 年啟動，為 Javascript 和 Typescript 提供安全的執行時間。它基本上由兩部分組成： TypeScript 前端和 Rust 後端。兩者之間的通訊是透過使用`TypedArrays`進行訊息傳遞來進行。 ![替代文字](https://dev-to-uploads.s3.amazonaws.com/i/aqzvipzkxwk1v45n22s9.png) > Deno 是 JavaScript/TypeScript 執行時，具有安全的預設設定和出色的開發人員體驗。 — Deno 網站在底層，我們找到了 Typescript 編譯器、V8 引擎和 Tokio 事件循環的快照版本。總而言之，以小於 10 MB 的二進位檔案或 Rust 箱子的形式提供。 API老化 ----- 早在 2010 年就取消了 Node 的承諾，這在早期階段對社群有所幫助。但隨著 JavaScript 開始變得越來越快並引入了等待和非同步功能，Node 的 API 開始老化。今天我們付出了巨大的努力來讓他們加快速度，同時保持一致的版本控制。許多 API 呼叫仍必須包裝在建構函式（如`promisify`中才能與`Promise`語法一起使用。這個額外的步驟增加了開發的開銷並增加了應用程式中的樣板檔案。相比之下，Promise 是 Deno 異步行為的本機綁定。 Rust 後端透過 Rust Futures 鏡像從 Typescript 前端接收的 Promise 物件。 Deno 中的非同步操作總是會傳回`Promise` 。 Node 的另一個值得注意的是它依賴`Buffer`物件來讀寫資料。為了實現瀏覽器介面的統一，Deno 在各處都使用了[`TypedArrays`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Typed_arrays) 。使用相同的資料結構時，在後端和前端讀寫檔案時保持一致會容易得多。零設定的 TypeScript ------- 如果你使用 Typescript，你就會知道它是一個出色的工具。它引入了一個可以隨著應用程式的成長而強制執行的類型系統。這透過提供靈活性減少了傳統靜態類型的開銷。專案可以在請求中進行部分類型化，並且類型覆蓋範圍可以隨著應用程式的成長而擴展。在 Node 中，Typescript 可以直接與`ts-node`一起使用，儘管在生產中必須小心。最安全、效能最好的選擇是使用`ts-node`進行開發。然後編譯為 javascript 以進行生產。開發的設定可能很複雜，尤其是與熱程式碼重新載入等其他功能一起使用時。另一方面，Deno 完全是關於 Typescript 的。它使用編譯器的快照版本並捕獲未更改的檔案。你想執行 Typescript 程式碼嗎？只需執行 Deno 二進位檔案即可。沒有配置。沒有喧囂。是不是很簡單，當然它也支援javascript。類似瀏覽器的套件解析 ---------- Node 目前的解析方案使模組解析過於複雜。該演算法在文件位置和命名方面提供了靈活性，但在複雜性方面做出了相當大的權衡。 `require`呼叫將先搜尋具有相同名稱和`.js` 、 `.json`或`.node`副檔名的檔案。如果指定的路徑不包含前導`'/'` 、 `'./'`或`'../'` node ，則假定該模組是核心模組或`node_modules`資料夾中的依賴項。如果名稱不匹配，核心模組 node 將檢查該位置的node\_modules。如果沒有找到任何內容，它將到達父目錄並繼續這樣做，直到到達檔案系統的根目錄。此外，資料夾可以在`package.json`檔案中指定為模組。 `require`函數也知道開始檢查的所有資料夾的`package.json`檔案。一旦找到資料夾，Node 將在其中查找`index.js`或`index.node`檔案。不必提供檔案副檔名的自由和`package.json`的靈活性會顯著增加複雜性並降低效能。 Deno 透過提供兩種類型的模組解析（相對解析和基於 URL 解析）來簡化演算法： ``` import * from "https://deno.land/std/testing/asserts.ts"; ``` 另外，解析演算法不使用`package.json`檔案或`node_modules`資料夾。它使用 ES 模組導入而不是`require` 。這使我們能夠使用現代方法進行程式碼管理，而無需預編譯器，並使我們再次更接近 Javascript 在瀏覽器中的使用方式。分散式套件管理 ------- 目前，無伺服器的採用率每年翻倍。開發人員通常將單體應用程式拆分為微服務。現在我們將微服務拆分為功能。為什麼？嗯，一方面，沒有人願意處理編排，除非我們也有。另一方面，分散式系統更加靈活，可以更快地改變。最重要的是，應用程式正在成為由更小且獨立的部分組成的系統。典型的 JavaScript 後端應用程式僅使用 0.3% 的程式碼。其餘部分由`node_modules`資料夾中的套件組成。而且許多在執行時幾乎不被使用。同時，整個生態系統依賴一個集中的套件管理器： `npm` 。 **Deno**帶來了一種分散式套件管理方法。套件可以透過 URL 解析並隨後捕獲。應用程式更輕，更少依賴單一的集中式套件註冊表。關於安全 ---- 在進行後端開發時，我希望安全性能夠在盒子之外發揮作用。我最不想考慮的是存取網路或檔案系統的 linter 檔案或 node 模組。在 Deno 中，內部函數不能像在 Node 中那樣任意呼叫 V8 API。 Deno 的 API 和 JS 引擎之間的通訊是集中且統一的，基於類型化陣列的訊息傳遞。 > 除非特別允許，否則腳本無法存取檔案、環境或網路。 — 德諾.蘭只有當使用者明確指定時，使用 Deno 執行的腳本才能存取檔案系統和網路。更好的是，可以使用 —allow 標誌在檔案、資料夾層級或網路路徑層級授予權限。這為開發人員提供了對執行時發生的讀寫操作的精細控制。 ``` $ deno --allow-net https://deno.land/std/examples/echo_server.ts ``` 與應用於從`npn`提取的依賴項的「信任」策略相比，預設的安全性是一項重大升級。借助 Deno，您可以執行和開發應用程式，並確信它們會執行預期的操作。加起來 --- 如果 Node 在今天建置， **Deno**就是它的樣子。它提高了安全性、簡化了模組解析並執行 Typescript。當我寫這篇文章時，我們仍處於 0.33 版本並且正在快速發展。我確信您來到這裡是因為您在某種程度上使用了 Node 或 Javascript。如果你像我一樣，你可能會喜歡它。但正如他們所說，愛某樣東西真正意味著放手。我期待看到 Deno 超越單純的腳本執行時，並聽到生產中的第一次經驗。只要開發人員繼續顛覆自己，我們總是能期待更快、更簡單、更可靠的軟體。最初發佈於[bogdanned.com](https://bogdanned.com/blog) 。 --- 原文出處：https://dev.to/bogdanned/on-deno-and-the-future-of-node-1l0p

0個讚 0留言 91瀏覽

小編精選 - 技術文章翻譯 · 02月25日

為初學者到專家提供的 101 個 Bash 指令和提示

0個讚 0留言 116瀏覽

小編精選 - 技術文章翻譯 · 02月21日

70 個 JavaScript 面試問題

0個讚 0留言 123瀏覽

小編精選 - 技術文章翻譯 · 01月21日

SQL 查詢優化 23 倍！！！

所以我現在已經進入 Web 開發大約 3 年了，專業也有一年多了，這是我處理一個與資料庫查詢最佳化相關的問題的時候，我不是 SQL 專家，我可以得到這份工作完成。沒有花哨的查詢、觸發器、預存程序等。無論如何，我不得不穀歌搜尋最後一個。長話短說..我們的 ORM (TypeORM) 把我們搞砸了.. ## 免責聲明：這並不是要誹謗 TypeORM 或任何 ORM。它們是為其建置目的而設計的特殊工具。我在最後附加了一些參考連結，這些連結是人們面臨類似問題的公開討論。無論如何，讓我們繼續這篇文章。 ## 問題！我們的提交表有超過 70 萬筆記錄，表現非常糟糕。從表中取得資料的最長時間超過 6 秒。 ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/l5dqlrbtn491upu8lwxs.png) 查詢相當簡單。我們所擁有的只是 4 個連接、幾個 where 子句（大約 4 個）、排序（在created_at time 字段上的 DESC）、限制和跳過。 ## 根本原因分析.. 導致我們的提交表大幅放緩的幾個因素如下：- - **索引** - 對用於連接表的欄位進行不正確的索引或未進行索引。 - **不必要的連接** - 我們的查詢中有一些不必要的連接，可以將其刪除以獲得更多效能。 - **空字串錯誤** - 我們程式碼中的一個錯誤，如果沒有為這些列提供使用者輸入，我們將與作為查詢的 where 條件一部分的所有列的空字串 (“”) 進行比較。 - **ORM** - ORM 正在執行一個超級愚蠢的查詢來獲取資料。這些是我在檢查程式碼和資料庫模式以及分析正在執行以獲取所需資料的查詢時發現的精確點。 ## 對提到的每個問題進行分析和測試。 ###<u>原因 1：索引</u> 在進行了一些谷歌搜尋並閱讀了人們的類似問題後，我發現我們的問題並不是那麼大。人們正在為數百萬行而苦苦掙扎，而我們的只是其中的一小部分，所以一定是我們做錯了什麼。早期解決這些問題的社區提出了許多建議。我發現進行適當的索引會有很大幫助。因此，為了進行測試，我從 beta 資料庫中獲取了提交內容，該資料庫擁有大約超過 **100k 記錄**。在沒有任何最佳化的情況下，執行整個過程平均需要 **2.3 秒**。（當然，這個時間不僅包括在資料庫上執行查詢的時間，還包括透過網路傳播資料的時間） ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2mgewrjv4khpzrst86nb.png) 在向列加入索引後，我確實發現它縮短了幾毫秒的時間，但這還不夠。它仍然在 **2 秒** 左右，而且往往不止於此。所以有點令人失望！無論如何，繼續下一個目標。 ### <u>原因 2：空字串錯誤</u> 因此，我們的時間從 **2.3** 秒縮短到了大約 2 秒，這對於索引來說並不算多。但後來我在我們的程式碼中發現了一個小錯誤，假設有四個輸入欄位供使用者根據四個不同的列鍵入和過濾結果。如果使用者沒有在任何輸入上鍵入任何內容（主要是在頁面首次載入時），且 API 呼叫會直接取得最新資料，而不進行任何過濾，僅進行連接和排序。因此，在那一刻，我們為資料庫中的所有列傳遞了“”字串，這似乎無害，但實際上發生的情況是，資料庫正在對所有四列進行查找，您猜對了“”字串。所以進行了大量的查找，實際上什麼都沒有。因此，當我將其更改為空（如empty/null）時（相當於從查詢中刪除where子句），查詢時間從**2.3秒變為1.3秒**。如果您想知道使用使用者提供的實際輸入進行過濾需要多長時間。大約**500ms**（這是可以接受的）。結論 - 即使您的資料庫使用所有可搜尋列進行索引，“”字串也不能很好地發揮作用。好的，我們正朝著正確的方向前進。我們整整縮短了 1 秒，但我們仍然必須將其控制在 **200/150ms** 以下，所以還有很長的路要走。 ### <u>原因 3：不必要的連接</u> 在查詢提交時，我們正在與不需要的比賽和課程表進行連接。因此，當所有內容都加入到程式碼中時，我們只是刪除了它，但這表明審閱者並沒有給予太多關注（我是其中之一）。 ### <u>原因 4：ORM</u> 這是造成最多的問題.. 好.. 問題!!. 所以有一種叫做 **主動記錄模式** 的東西，TypeORM 為我們提供了使用類似 JSON 的物件產生 SQL 查詢的東西，一個例子就是。 ``` model.find({ select: { userName : true, firstName : true }, where: { userName : “SomeUsername” }, relations: { user : true, contest: true, problem: true }, order: { created_at : “ASC/DESC” , skip: 0, take: 10, }) ``` 因此，這使得開發變得快速、簡單，對於不擅長編寫原始 SQL 查詢的開發人員來說，感覺非常直觀，因為這是最抽象的版本，您實際上是在建立 JSON 物件來產生 SQL 查詢。這種方法看起來不錯，而且大多數時候都有效，但在我們的例子中，它做了一些非常愚蠢的事情，我不會輸入它在做什麼，這樣你就可以自己看到查詢。簡而言之，它正在執行兩個查詢，首先對於這種情況根本不需要，它可以通過我稍後編寫並測試的一個簡單的單個查詢輕鬆完成。它不僅執行兩個單獨的查詢（原因尚不清楚，因為這是一個已知問題，有時在使用typeorm 的活動記錄模式時發生），它還將四個表連接兩次，每個查詢一次，然後還排序兩次各一次。（這實際上沒有任何意義）這也是表演受到最大打擊的地方。自己看看下面的查詢。 ``` SELECT DISTINCT `distinctAlias`.`Submission_id` AS `ids_Submission_id`, `distinctAlias`.`Submission_created_at` FROM (SELECT `Submission`.`id` AS `Submission_id`, ... more selects FROM `submission` `Submission` LEFT JOIN `problem` `SubmissionSubmission_problem` ON `SubmissionSubmission_problem`.`id`=`Submission`.`problemId` LEFT JOIN `user` `SubmissionSubmission_user` ON `Submission_Submission_user`.`id`=`Submission`.`userId`) `distinctAlias` ORDER BY `distinctAlias`.`Submission_created_at` DESC, `Submission_id` ASC LIMIT 10 ``` ``` SELECT `Submission`.`id` AS `Submission_id`, `Submission`.`language` AS `Submission_language`, `Submission`.`verdictCode` AS `Submission_verdictCode`, `Submission`.`tokens` ... shit ton of selects FROM `submission` `Submission` LEFT JOIN `problem` `SubmissionSubmission_problem` ON `SubmissionSubmission_problem`.`id`=`Submission`.`problemId` LEFT JOIN `user` `SubmissionSubmission_user` ON `Submission_Submission_user`.`id`=`Submission`.`userId` WHERE `Submission`.`id` IN (?, ?, ?, ?, ?, ?, ?, ?, ?, ?) ORDER BY `Submission`.`created_at` DESC ``` 所以這兩個查詢是問題的主要原因，也是主要原因之一。因此，我編寫了一個簡單的原始 SQL 查詢來執行與它嘗試使用 2 個單獨的查詢執行的完全相同的操作，查詢如下：- ``` SELECT Submission.id, Submission.language, Submission.verdictCode, ... FROM submission AS Submission LEFT JOIN problem ... LEFT JOIN user ... ORDER BY Submission.created_at DESC LIMIT 10 ``` 當我們執行這個查詢時，它的執行時間僅為 **100ms!!!** 因此，我們現在從 **1.3** 秒移至 **100ms**，總體從 **2.3** 秒移至 **100ms** 效能提升超過 **23 倍。** 之後我就去睡覺了。仍然需要做更多的測試，並嘗試找出邊緣情況（如果有），並提出為此編寫查詢的最佳方法。目前，我正在考慮使用 TypeORM 提供的儲存庫模式或查詢建構器模式。第二天：又來了.. ### <u>全文索引</u> **全文索引**可以提高從這些索引列中搜尋單字和短語的效率，我們也可以嘗試一下。（這是我的同事 Jay 提出的一個非常好的觀點，它進一步提高了表現）。 ###<u>發現了一些更重要的點。</u> 在 MySQL 中最佳化具有唯一索引的資料列上的「LIKE」查詢時，可以採用一些策略來提高效能。以下是一些建議： 1. **索引優化：** - **使用全文索引：** 如果您的「LIKE」查詢涉及在列中搜尋單字或片語，請考慮使用全文索引而不是常規唯一索引。全文索引是專門為基於文字的搜尋而設計的，可以提供更快、更準確的結果。 - **使用排序規則：** 確保列的排序規則不區分大小寫和重音。這可以透過使用「utf8_general_ci」或「utf8mb4_general_ci」等排序規則來實現。它允許更有效地利用索引，因為搜尋變得不區分大小寫和重音。 2. **查詢最佳化：** - **前綴搜尋：**如果您的`LIKE`查詢在末尾使用通配符（例如，`column LIKE 'prefix%'`），索引仍然可以有效地使用。但是，如果通配符位於開頭（例如“column LIKE '%suffix'”），則不會使用索引。在這種情況下，請考慮使用替代技術，例如全文搜尋或儲存列的反向值以實現高效的後綴搜尋。 - **最小化通配符：** 模式開頭的通配符（`'%suffix'`）會使查詢速度明顯變慢。如果可能，請嘗試建立查詢，使通配符僅出現在模式的末尾（「前綴%」）。 - **參數綁定：** 如果您從應用程式內執行「LIKE」查詢，請使用參數綁定或準備好的語句，而不是直接連接查詢字串。這有助於防止SQL注入並允許資料庫更有效地快取執行計劃。 3. **快取和查詢結果：** - **快取查詢結果：** 如果`LIKE`查詢結果相對靜態或不需要即時，可以考慮實作像memcached或Redis這樣的快取機制。快取可以透過直接從記憶體提供結果來顯著縮短反應時間。 - **物化視圖：** 如果經常執行「LIKE」查詢且資料列的資料相對靜態，請考慮建立物化視圖來預先計算並儲存「LIKE」查詢的結果。如果查詢物化視圖所帶來的效能提升超過了額外的儲存和維護需求，則此方法可能會很有用。值得注意的是，這些優化策略的有效性可能會根據您的特定用例而有所不同。 ### 經過所有測試後建議的改進點。 1. 修正將空字串傳遞到 where/過濾條件的問題。 2. 在效能至關重要的讀取操作中，轉而使用查詢建構器而不是活動記錄模式。 3. 在用於搜尋和過濾的欄位中新增索引。另外，在不唯一且用於搜尋的列上新增全文索引。 4. 刪除/避免不必要的連線。如果可能的話，重組架構以在必要時複製資料。 5. 使用 LIKE 運算子搜尋時，使用「prefix%」模式，而不是我們使用的預設模式「%suff+pref%」。使用前綴模式有助於資料庫使用索引並提供更好的結果。儘管如此，我們成功地將查詢時間從 **7 秒** 降低到 **<=150 毫秒**，這樣做後感覺很好，因為這是我第一次涉足性能和優化並尋找從我們已有的資源中榨取更多資源的方法。特別感謝[Mitesh Sir](https://www.linkedin.com/in/miteshskj/) 在這次調查期間指出了潛在的原因並引導我走向正確的方向，並一遍又一遍地重新啟動測試伺服器😂因為由於記憶體限制，在多次執行測試後，資料庫會變得非常慢。如果您想更多地談論與這一切相關的內容，請在 X 上關注我，https://twitter.com/RishiNavneet ### 參考 1. https://github.com/typeorm/typeorm/issues/3857#issuecomment-714758799 2. https://github.com/typeorm/typeorm/issues/3857 3. https://stackoverflow.com/questions/714950/mysql-performance-optimization-order-by-datetime-field 4. https://stackoverflow.com/questions/22411979/mysql-select-millions-of-rows 5. https://dba.stackexchange.com/questions/20335/can-mysql-reasonously-perform-queries-on-billions-of-rows 6. https://stackoverflow.com/questions/38346613/mysql-and-a-table-with-100-millions-of-rows 7. https://github.com/typeorm/typeorm/issues/3191 PS - 這些改進很久以前就完成了，我只是懶得發布它😬。 --- 原文出處：https://dev.to/navneet7716/optimizing-sql-queries-h9j

0個讚 0留言 240瀏覽

小編精選 - 技術文章翻譯 · 12月05日

使用 VSCode 更快輸入程式碼的技巧分享

0個讚 0留言 719瀏覽

站長阿川 · 01月02日

JavaScript 系列一：第6課 ── 認識資料型態與轉換

## 課程目標學會「數字」資料型態學會基本的資料型態轉換 ## 課程內容在之前的課程中，我們學會了宣告字串、以及字串的連接 ``` var str1 = '新年'; var str2 = '快樂'; var str3 = var1 + str2; alert(str3); ``` 這課我們要學「數字」這種資料型態以及一些基本操作 ``` var x = 30; var y = 5; var z1 = x + y; var z2 = x - y; var z3 = x * y; var z4 = x / y; alert(z1); alert(z2); alert(z3); alert(z4); ``` 以上是加減乘除的範例，很簡單吧！要注意的是，長得像數字的字串，其實依然是字串 ``` var a1 = '100'; var a2 = 100; ``` 上面的 `a1` `a2` 兩個變數，看起來很像，但資料型態不一樣雖然直接進行字串連接或者加減乘除，程式不會出問題，但那其實是 JavaScript 引擎知道你懶惰，「猜測」你需要型態轉換，自動幫你轉換但其實手動把型態轉換清楚比較好，比較不會有誤會比方說，上面的 `a1 + a2` 如果都當成數字，會是 `200`；如果都當成字串，那字串連接會是 `'100100'` 這種情況就很容易造成出錯，所以要養成習慣，把型態轉換清楚要把數字轉成字串，可以使用「數字」這種資料型態內建的 `.toString()` 函式 ``` var a1 = '100'; var a2 = 100; var a3 = a1 + a2.toString(); alert(a3); ``` 要把字串轉成數字，也有一個內建函式 `parseInt()` 可以使用 ``` var a1 = '100'; var a2 = 100; var a3 = parseInt(a1) + a2; alert(a3); ``` 這些範例都去 jsfiddle 跑跑看，就會很清楚了！ --- 使用函式的時候，有時像在直接呼叫一個「函式」，例如 `alert()` `parseInt(a1)` 有時又像在呼叫「物件」的「函式」，例如 `document.getElementById()` `a2.toString()` 你或許會覺得，怎麼不設計成 `a1.toInt()` 跟 `parseString(a2)` 呢？這些其實是程式語言設計者的主觀喜好、偏好、習慣而已，不重要，反正能跑就好了，你就先用就對了 --- 有件事要提一下，前面的課程，有說到如何取得用戶輸入的內容 ``` var str = document.getElementById('keyword').value; ``` 在 JavaScript 之中，用戶在 html 元素輸入的內容，一律都會是「字串」就算用戶是輸入阿拉伯數字，在 JavaScript 中拿到值之後，如果需要數學計算的話，要記得把型態轉成數字 ## 課後作業接續前一課的作業，雖然詳細的報價，你希望在電話中跟對方談，因為要了解客製化細節，才能報價但是你覺得先在網頁上，顯示初步的報價，可以節省一些時間，比較有效率這次的作業要用簡單的數學，來初步顯示報價 --- 目前的欄位有顧客名稱、服裝分類、服裝類型請再增加一個文字輸入欄位，讓客戶能輸入「訂購數量」為了簡單起見，男裝不論類型，一件都報 600 元；女裝不論類型，一件都報 500 元在點擊訂購按鈕之後，訂單細節裡面，顯示「初步估價」給客戶看，類似這樣： ``` －－－－－－－－－－｜您的訂單　　　　｜｜顧客姓名：ＸＸＸ｜｜服裝分類：ＸＸＸ｜｜服裝類型：ＸＸＸ｜｜訂購數量：ＸＸＸ｜｜初步估價：ＸＸＸ｜－－－－－－－－－－ ``` 做出以上功能，你就完成這次的課程目標了！

2個讚 42留言 2,080瀏覽

站長阿川 · 01月02日

JavaScript 系列一：第2課 ── 基本的變數操作、從 html 取得內容

## 課程目標學會基本的變數賦值學會基本的字串連接能從 html 元素中，得到用戶輸入的內容 ## 課程內容在上一課的內容中，我們這樣來顯示訊息視窗 ``` alert('你點擊了按鈕！'); ``` 像這樣單引號包起來的內容 `'你點擊了按鈕！'` 我們叫「字串」，是一種資料類型除了直接把字串當參數傳給函數之外，還可以先把字串紀錄在「變數」之中，方便重複使用 ``` var message = '你點擊了按鈕！'; alert(message); ``` 就跟函數名稱一樣，變數名稱是隨便命名的，取一個自己看得懂的名稱就行了記錄到變數之後，就可以到處重複使用，不用每次手寫整段資料內容不論是字串或者變數，都可以連接起來使用 ``` var text1 = '恭喜'; var text2 = '發財'; alert(text1 + text2); alert('萬事' + '如意'); ``` 除了「字串」這種資料類型之外，還有「數字」等等其他類型，之後課程會提到 --- 不論是購物網站、社群網站、各種網站，一定會經常需要用戶輸入的內容有一個簡單的方法可以取得用戶輸入內容 ``` <input id="keyword" type="text" /> <button onclick="myFunction()">Click me</button> ``` ``` function myFunction() { var str = document.getElementById('keyword').value; alert(str); } ``` 函數中的 `document` 是一個 JavaScript 在瀏覽器中內建的「物件」，這個物件代表網頁當下的狀態，有很多資料、函數可以呼叫使用後面的 `.` 代表去呼叫這個「物件」的「函數」，或者去存取這個「物件」的「屬性」這邊的 `document.getElementById('keyword')` 代表以 `'keyword'` 為參數去呼叫 `getElementById`函數這函數會去找出網頁中 id 為 `keyword` 的元素，元素在 JavaScript 中也是一種物件後面的 `.value` 就是去存取元素的 value 屬性。各種輸入相關的元素，都會把用戶的輸入內容存在 `value` 這屬性之中使用以上的幾段程式碼，可以輕鬆地取得用戶輸入的內容請在 jsfiddle 試試看上面的範例，把輸入欄位與按鈕寫在 html 區塊，把函數定義寫在 JavaScript 區塊，實驗一下、玩玩看！ ## 課後作業接續第一課的作業，你的「線上下單」頁面，目前有個訂購按鈕你對按下按鈕的導購訊息，不太滿意，你希望能顯示客戶的名字，看起來更專業這課的作業要來改善這個「線上下單」頁面的功能 --- 請使用 jsfiddle，多加一個文字輸入欄位，讓客戶能輸入名字在客戶點擊訂購按鈕之後，跳出的訊息會顯示：「ＸＸＸ您好！謝謝您對我們的衣服有興趣！請致電 0987-654-321，會有專人提供您報價！」請稍微替這個輸入客戶名字的欄位加一些 css 屬性，弄得漂亮一點才專業做出以上功能，你就完成這次的課程目標了！

4個讚 64留言 4,072瀏覽

歡迎發文

💡 記錄日常工作的實踐、心得

💡 發表對生活和職場的感悟

💡 針對感興趣的事件發表隨筆或者雜談

💡 詳細介紹你掌握的一門語言、一個技術，或者一個興趣

💡 或者，就直接把你的部落格搬到這裡（支援 API 可以撈）